Many applications, such as real-time streaming, are particularly sensitive to bandwidth limitations, network delay and packet loss. To minimize the impact to applications when such impairments do arise, a variety of Quality of Service (QoS) techniques and (QoS-aware) protocols can be implemented.
For example, RTP (Real-time Transport Protocol), and its companion protocol, RTCP (Real-time Control Protocol), provides for periodic control packets (so-called Sender Report (SR) and Receiver Report (RR) packets) to allow an application to monitor the quality of data distribution. Sender and Receiver Reports do not acknowledge individual RTP packets but rather report various statistics, such as the variation value of the arrival gap of RTP data packets (Interarrival Jitter) and fraction of RTP data packets from the source lost since the previous RR packet was sent (Fraction Lost). A round-trip time (RTT) delay and network delay can also be determined using time-based information (LSR and DLSR) carried in the reports.
However, network delay can also be a function of receive buffer management as well as router and switching equipment configurations. Thus, in certain circumstances, a determination of network delay using RR packets does not accurately reflect the actual network environment. In addition, the fraction lost number reported by RR packets is generated based on original data transmissions, i.e. without considering requested retransmissions that did not arrive at the receiver. In other words, it does not account for loss of any data in the forward transmission path. Furthermore, the fraction lost number only provides an indication of the short-term packet loss rates to a receiver. Thus, there may be some deviation compared to the actual value.
An extension to the RTCP for the Audio-Visual Profile, “RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)”, enables receivers to provide, statistically, more immediate feedback to senders, allowing for feedback-based repair mechanisms (e.g. retransmissions) to be implemented. However, unlike TCP, RTP/UDP does not mandate congestion control by reducing the packet transmission rate.
The format of a general-purpose feedback packet defined by RFC 4585 is shown in FIG. 5a. It includes, among other things, a feedback message type (FMT) field, which identifies the type of the feedback (transport layer feedback message, payload-specific feedback messages, or application layer feedback messages), and a Feedback Control Information (FCI) field, which is any additional information included in the feedback message for the different types of feedback. If multiple types of feedback messages need to be conveyed, then several RTCP feedback messages must be generated.
Where the feedback packet is a NACK packet (ACK packets are excluded from later versions of RFC 4585), the FCI field comprises a packet identifier (PID) field and a bitmask of following lost packets (BLP) field (16 bits) (shown in FIG. 5b). The BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID. Bit i of the bit mask is set to ‘1’ if the receiver has not received RTP packet number (PID+i); bit i is set to ‘0’ otherwise. However, the sender must not assume that a receiver has received a packet because its bit mask is set to 0. All the sender knows is that the receiver has not reported them as lost at this time.
In view of these shortcomings, a need exists for improved ways to determine network conditions based on more accurate feedback information, to facilitate better control of data transmission and hence quality of service.